The removeObjects() cleanup helper silently ignored all DeleteErrors via
ignore(r.get()), masking transient server-side failures. When the batch
delete of 1050 objects returned partial errors (e.g. SlowDown,
InternalError), those objects remained in the bucket and the subsequent
removeBucket() call failed with BucketNotEmpty — surfacing a cleanup
race as a false test failure.

Replace the single ignore() call with two focused helpers:

- retryRemoveObject(): retries a single object with exponential backoff
  (500ms base) up to MAX_DELETE_RETRIES attempts. Accepts
  NoSuchKey/NoSuchVersion silently (already gone), retries
  SlowDown/InternalError/RequestTimeout/ServiceUnavailable, and
  propagates anything else immediately.
- removeObjects(): fully consumes the batch-delete iterator first (so
  all 1000-object HTTP batches are sent), then delegates each
  DeleteResult.Error to retryRemoveObject() individually.

DeleteResult.Error only exposes objectName() via ErrorResponse (no
versionId), so a HashMap<String,List<ObjectWriteResponse>> index
preserves correct versioned-delete semantics by storing all responses
keyed by name and retrying every (name,versionId) pair on a miss.

Switch Result<?> to Result<DeleteResult.Error> to restore compile-time
type safety and eliminate the unchecked cast. Drain the full server
response before throwing on a non-transient error so OkHttp can reuse
the connection slot. Restore the thread interrupt flag if
Thread.sleep is interrupted. Wrap TRANSIENT_DELETE_CODES in an
unmodifiable set. Guard the testRemoveObjects finally block so the
redundant cleanup batch is only sent on failure. Add bucket name to
error messages and document the retry-by-name re-queueing trade-off.

MinioAsyncClient.removeObjects() sets completed=true as soon as any
1000-object chunk returns errors, silently dropping all subsequent
chunks in that call. When toDelete exceeds 1000 entries and a transient
error hits the first chunk, objects in later chunks are never attempted
and not carried into the retry set, leaving the bucket non-empty.

Fix by iterating toDelete in DELETE_BATCH_SIZE slices and issuing a
separate removeObjects() call per slice so each slice is always fully
processed regardless of errors in other slices.

After capturing a non-transient error, the previous code continued
issuing removeObjects() calls for all remaining chunks before throwing.
Move the nonTransientErr check to after each individual chunk's response
is drained so no further delete RPCs are made once a fatal error is seen.

Rename MAX_DELETE_RETRIES to MAX_DELETE_ATTEMPTS to better reflect
that the constant bounds attempts, not retries. Include err.message()
in the non-transient IOException for richer diagnostics. Track
failedNames across iterations and include a 5-object sample in the
exhaustion IOException to aid debugging when all retries are consumed.

If removeObjects() in the try block throws, handleException() rethrows
it. A second throw from the finally cleanup would then mask the original
exception, making the test failure harder to diagnose. Wrap the cleanup
call in try/catch so the original exception propagates unmasked.

…ailure

Replace byName index, retryNames set, and toDelete rebuild loop with a
single anyTransient boolean flag. Retry the full object list on transient
errors rather than narrowing to failing names — already-deleted objects
are silently ignored by S3 and MinioAsyncClient filters NoSuchVersion.

…ailure

Address review feedback on PR minio#1700:
- Use Exception instead of IOException in removeObjects() helper
  for consistency with the rest of the test class.
- Remove the finally/succeeded retry in testRemoveObjects() now that
  removeObjects() retries transient failures internally; drops the
  associated DE_MIGHT_IGNORE SpotBugs suppression.